Managing creative people

One area that I have often thought about is related to the management of smart, highly-motivated, creative people. Unfortunately, I have seen too many cases where things go horribly wrong. I know there are tons of books on this subject... but perhaps there are none that give a simple-to-understand and prescriptive advice?

In any case, here are my thoughts re: steps that can help create a high-energy and high-output team:

Ensure robust hiring process that hires creative (not just “quick thinking”) people. Most companies that pride themselves with "tough" interview process miss out on this important distinction.

Create an “open market” within the company/group with free availability of information.

Flexible internal transfer process. Provide freedom to people to pick the project of their liking (and, if required, to quickly move to other projects). This is needed to complement the free availability of information.

Ensure managers have strong technical background; eliminate “people managers”.

Create an open (but secret) and free-for-all internal rating system. Almost no company/group that I know of does this. 360-degree reviews are a simplified (but useful!) version of this appraisal process. This is an extremely important requirement because it will help people understand the contributions made by other people and to appreciate how everyone is working together to create a product or to deliver a project.

The single biggest bane of the software industry, though, is the concept of "people managers". However well-intentioned, people managers are unable to fully appreciate the value of contributions being made by different people. Chaos ensues: morale suffers, productivity dips, people quit. But, unfortunately, it is difficult to measure these things and, therefore, the managers thrive.

To circumvent these problems, some of the more innovative internet companies have opted for flatter organizations with either manager's "role" being played by a technical person or manager's being downgraded to first-level managers (with hands-on involvement in low-level design, coding, etc.). Both of these are improvements over earlier systems -- but neither is completely satisfactory. In most software development projects, historical perspective is useful and, therefore, continuity is critical. Further, low-level design, coding, etc. are often not the best use of the experience gathered by senior technical people.

There is a need to rethink the whole technical management structures in software companies.